第8章 アジャイルな計画づくり：現実と向き合う
8.1 固定された計画の問題
最初のプロジェクトは好調でも、さまざまな影響でプロジェクトがうまくいかなくことがある
開発主要なメンバーが抜けてしまった
リリース時期がはまった
このような事象に解決するためには4つの基準にそったプロジェクト計画をしないといけない
顧客にとって価値ある成果を届けられる計画
わかりやすくありのままを伝える、誠実な計画
約束したことを守り続けられる計画
必要に応じて変更できる計画
8.2 アジャイルな計画づくり
プロジェクトでこなすべきTODOタスクをマスターストーリーリストという
これはプロジェクトとして必要なタスクであり、ユーザー目線の機能で分解したものをユーザーストーリーという
ソフトウェアの開発スピードをさすのがベロシティ
ソフトウェアの開発が完了の目安を定義したものイテレーションという
プロジェクト計画完了の目安を導く公式は以下
イテレーション数 = 作業量の合計 / チーム予想のベロシティ
Ex: 1回のイテレーションで10ポイント消費するプロジェクトで、100ポイントあるストーリーを解消するには、10イテレーションかかる計算になる。1イテレーションを1週間と定義すると、10週間で完了する計算になる。
ポイントは最初のイテレーションは当てにならない。実際の運用して期待通りにならないようなことが起きた時には、スコープを調整して対応する
8.3 スコープを柔軟に
基本的にスコープは柔軟にしておくこと
仮に顧客からストーリー追加の要望が来た場合は、それ同等の既存のストーリーをスコープを外すようにする
もしくは、追加のストーリ追加の要望が来た場合は、期日を延長することも検討する
→だがこれは、アジャイルサムライ的にはおすすめしない。IT業界ではあるあるのため。
上記のどちらを実施したとしても、スコープは柔軟にしておくことが大事。
仮にストーリーの数が膨大でかるスコープの柔軟が難しい場合は、正直に顧客に伝えること。顧客が諦めてくれるまでスコープの調整を図る
8.4 初回の計画づくり
STEP1：マスターストーリーリストを作る
顧客がソフトウェアで実現したいことのリストを作成
見積もりを行い優先順位を顧客と決める
1ヶ月から6ヶ月の期間内の収める
リストの中からリリースを定義する
リリース：ストーリーの中からまとめたサブセットとして抽出しまとめたもの。そのリリースを1回のデプロイとする。一番最初のリリースは本当に価値があるフィーチャーに厳選する
STEP2：プロジェクト規模を見極める
マスターストーリーリストのリリースがどのくらい期間がかかるかを計算する
STEP3：優先順位をつける
ストーリーリスト毎に優先順位を顧客とつける
顧客が考えているビジネスインパクトが大きいと考えるものは優先順位を高めにつける。
開発メンバー側で解消したいストーリー（リスクを考慮して）などあれば提案する
STEP4：チームのベロシティを見積もる
基本のベロシティの計算以下
チームのベロシティ = 完了させたストーリーポイントの合計 / イテレーション数
プロジェクトを開始したばかりは安定しないが、3~4回すれば安定する
完了の定義もきちんとおこなうこと。顧客に価値をあたえるとうはどういうことかを整理する
ステークホルダーには見積りは推測でしかないことを認識してもらうこと
STEP5：期日を仮決めする
二つのやり方がある
期日固定
期日を固定するやりかた
途中で対応しないといけないストーリーがあると、スコープを調整しないといけない
期日を固定するので開発メンバーに緊張感がうまれる
フィーチャーセット固定
全てのフィーチャーを開発完了するまで開発をし、期日を柔軟にしておくこと
こちらもスコープは柔軟にしておく必要はある。後から重要なフィーチャーが発生することはある。
重要なフィーチャーセットの場合は、期日を調整対象と判断する（期日調整のリスクは相談しないといけない）
8.5 バーンダウンチャート
チームのベロシティや残りのタスク量がなどが確認できるチャート
以下の内容が確認できる
どれだけタスクを完了したのか
どれだけ仕事が残っているのか
チームのベロシティ
いつ頃すべてを完了させられそうか
https://i0.wp.com/mintaku-blog.net/mintaku/wp-content/uploads/2021/05/IMG_5751-scaled.jpg?w=1600&ssl=1
上記のチャートはプロジェクトの実態が確認できるので、ステークホルダーに共有するときの材料に使える（プロジェクトマネジメントの期待値調整ができる）
逆にバーンダウンチャートといって右上に積み上げていくチャートもある
8.6 プロジェクトを途中からアジャイルにしていく
今やっている開発がうまくいかない場合
またすでにプロジェクトすでに始まっている場合は、最低限以下の5つの質問は確実の答えられるようにしておこう
このプロジェクトにいるのはなぜ？
成し遂げようとしてることは何？
顧客は誰？
解決すべき主要な課題は何？
最終判断を下すのは誰？
一つでもおぼつかない場合は、インセプションデッキの調整をはじめにする
とにかく早く、何らかの成果をあげなきゃいけない場合
今のプロジェクト計画を捨てて、新たにアジャイルな開発をたてる
そうして最小限の価値をお客様に提供する
もし計画を変えれない場合
小さいフィーチャーを選らんでアジャイルな開発をする
毎週価値がある成果（完了させたフィーチャー）をあることMTGで共有する
8/7 現場で実践する
シナリオ1: お客さんが新しい要求を発見したら
期日を延ばすか、スコープを変更するかを対応する。判断するのは顧客なので、感情的になる必要は何
顧客が決めかねている場合は、「あるといいな（Nice-to-have）」リストを作って管理すること。これはスコープ範囲外として対応する
シナリオ2: 思っていたほどは速く進んでいないとき
事前に顧客には「最初の計画は過信しないでほしい」と言っているので、必要に応じて調整をする
大事なことは開発速度が進んでいないことについて話し合うこと。あるがままの状態を顧客につたえること
スパルタ戦士の流儀
無駄を省いたシンプルのフィーチャーでも期日に間に合わない場合は、計画を見直すべき
スパルタ式の実装は、最も重要でかつ無駄を省いたフィーチャーを決めて開発をする。その実績をもとの他のストーリーを相対的に見積もるようにする
プロジェクトをすすめていって間に合わないと判断したら、計画の変更が必要な件を共有する。客観的な事実で調整することができるので、後になって判明するよりは早いうちからわかっていた方がいい。正々堂々と挑もう
シナリオ3: 大切なチームメンバーがいなくなったら
すなおにベロシティに影響があることをつたえ、スプリントがどのくらい追加になることを共有する
いなくなったメンバーと同じぐらい優秀な人がくることをわかっても、スプリントを回すまで同じメンバーとして扱わないこと。そこは懐疑的に考えていたほうがいい
シナリオ4: 時間が足りなくなったら
スコープを調整する。基本に忠実に。
スパルタ式に則ると最低限のフィーチャーに調整してリリースすることを顧客と模索する。信頼関係の構築にもつながる。